A database is a collection of related data items. To perform various tasks, users access data items stored in the database via transactions. A database management system supports transactions to access the data items stored in the database, and uses data structures such as indices to manage access to the data items.
Disk-based Relational Database Management Systems (RDBMS) use disk storage to store and access databases. Much of the work that is done by a conventional, disk-optimized RDBMS is done under the assumption that the data items and related data structures primarily reside on disk. Optimization algorithms, buffer pool management, and indexed retrieval techniques are designed based on this fundamental assumption. One problem with disk storage is that access to the data items and to the data structures is relatively slow.
Even when an R-DBMS has been configured to hold all of its data items and data structures in main memory, its performance is hobbled by assumptions of disk-based data residency. These assumptions cannot be easily reversed because they are hard-coded in processing logic, indexing schemes, and data access mechanisms.
In-memory relational database systems (also called main-memory relational database systems) are deployed, such as in the application tier, and operate in physical memory using standard Structured Query Language (SQL) interfaces. By managing data in memory and optimizing the data structures and data access algorithms, in-memory database systems are able to provide improved responsiveness and throughput compared even to fully cached, disk-based RDBMS. For example, an in-memory database system is designed with the knowledge that the data items reside in main memory, and is thus able to take more direct routes to the data items, reducing lengths of code paths, and simplifying algorithms and data structures.
When the assumption of disk-residency is removed, complexity is reduced. The number of machine instructions drops, buffer pool management disappears, extra copies of the data items and/or data structures are not needed, and indices shrink. The database design becomes simpler and more compact, and requests for data items are executed faster. Some in-memory database systems provide persistent (non-volatile) storage of data, such as by archiving data from main memory to disk, or by maintaining a non-volatile transaction log. Unlike disk-based RDBMS, however, some in-memory database systems do not guarantee persistence of all data, such as by not gating a commit of a transaction by the non-volatile logging of the transaction.
In-memory database systems are sometimes less reliable than disk-based systems because of factors such as: the storage (such as main memory) is volatile; an environment in which the in-memory database systems are deployed is more hostile; and a type of hardware platform on which the in-memory database systems run is less reliable. Techniques such as data replication and using active and standby systems are used to increase reliability and availability. In one form of replication, write-through schemes allow modifications to an in-memory database system to be “written through” to a backend (primary) database system. Write-through to a backend database system thus improves data persistence, since if the in-memory database system fails, data that has been written through remains in the backend database system and is retrievable from there. However, it is desirable to have techniques with both improved data persistence and improved data availability, so that a failure (such as a crash) of a single in-memory database system does not (even temporarily) cause a loss of access to the data.